apps/console/src/routes/TenantsPage.tsx-35-50 (1)

35-50: ⚠️ Potential issue | 🟡 Minor

Simplify modulesByNamespace — the outer condition is dead code and the inner filter is O(n²).

Line 43's outer check name !== "info" || count > 1 is effectively a no-op: the inner block only pushes when name !== "info", so when name === "info" the inner always skips regardless of the outer count, and when name !== "info" the outer is already true. The net behavior is simply "push every non-info module" — the "info is default, keep it when it's the only one" intent implied by the comment is never realized. Additionally, the .filter(...) inside forEach makes this O(n²) over all modules.

If "info" should always be hidden, drop the dead logic. If "info" should be shown only when it's the sole module in the namespace, precompute counts once.

🛠 Proposed fix (drop dead logic, single pass)

-  // Group modules by namespace
-  const modulesByNamespace = useMemo(() => {
-    const map = new Map<string, string[]>()
-    modulesData?.items.forEach((mod) => {
-      const ns = mod.metadata.namespace
-      if (!map.has(ns)) {
-        map.set(ns, [])
-      }
-      // Only include info module if it's not the only module (info is default)
-      if (mod.metadata.name !== "info" || (modulesData?.items.filter(m => m.metadata.namespace === ns).length ?? 0) > 1) {
-        if (mod.metadata.name !== "info") {
-          map.get(ns)!.push(mod.metadata.name)
-        }
-      }
-    })
-    return map
-  }, [modulesData])
+  // Group modules by namespace (hide the default "info" module)
+  const modulesByNamespace = useMemo(() => {
+    const map = new Map<string, string[]>()
+    modulesData?.items.forEach((mod) => {
+      if (mod.metadata.name === "info") return
+      const ns = mod.metadata.namespace
+      const list = map.get(ns)
+      if (list) list.push(mod.metadata.name)
+      else map.set(ns, [mod.metadata.name])
+    })
+    return map
+  }, [modulesData])

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/TenantsPage.tsx` around lines 35 - 50,
modulesByNamespace currently performs an O(n²) filter and contains dead logic —
change it to a two-step single-pass approach: first build a Map of namespace ->
count from modulesData?.items (use mod.metadata.namespace) to know how many
modules per namespace, then iterate modulesData?.items once and push
mod.metadata.name into map only for non-"info" modules, and for "info" push it
only when the precomputed count for that namespace is 1; update references to
modulesByNamespace, modulesData?.items, mod.metadata.name and
mod.metadata.namespace accordingly to remove the inner .filter and the redundant
outer condition.

apps/console/src/routes/detail/VncTab.tsx-33-33 (1)

33-33: ⚠️ Potential issue | 🟡 Minor

Simplify the RFB import to use module.default directly.

The @novnc/novnc@1.6.0 package exports RFB as a standard ESM default export (export default class RFB), so module.default should be the RFB class directly. The current fallback chain (module as any).default?.default || module.default || module is overly defensive and the final fallback to module (the entire namespace object) would fail on new RFB(...) with a confusing error. Replace with simply module.default to get the actual RFB constructor, with a proper type annotation instead of any.

This applies to both line 33 and line 131.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/detail/VncTab.tsx` at line 33, The RFB import
fallback chain is overly defensive and can yield the namespace object instead of
the constructor; replace occurrences where RFB is resolved (the expression
currently using (module as any).default?.default || module.default || module)
with a direct module.default access and add a proper type for the module (use
the RFB constructor type) instead of casting to any; update both places
referenced in VncTab.tsx (the resolution at the original import and the second
occurrence around line 131) so new RFB(...) receives the actual class
constructor.

apps/console/src/routes/detail/SecretsTab.tsx-185-187 (1)

185-187: ⚠️ Potential issue | 🟡 Minor

Import Tenant and narrow the type cast instead of using as any.

The Tenant interface with status.namespace is properly defined in @cozystack/types, making the as any cast unnecessary. Since the code already checks isTenant before accessing the namespace, casting to Tenant provides proper type safety and satisfies the @typescript-eslint/no-explicit-any rule.

🔧 Proposed fix

-import type { ApplicationDefinition, ApplicationInstance } from "@cozystack/types"
+import type { ApplicationDefinition, ApplicationInstance, Tenant } from "@cozystack/types"

  const ns = isTenant
-   ? (instance.status as any)?.namespace ?? instance.metadata.namespace ?? ""
+   ? (instance as Tenant).status?.namespace ?? instance.metadata.namespace ?? ""
    : instance.metadata.namespace ?? ""

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/detail/SecretsTab.tsx` around lines 185 - 187,
Replace the use of a broad any cast when deriving ns: instead cast instance to
Tenant when isTenant is true and access status.namespace, i.e. narrow the type
instead of using "as any"; update the expression that computes ns (the variables
isTenant, instance.status, instance.metadata and ns) to cast instance to Tenant
in the branch where isTenant is true so TypeScript uses Tenant.status.namespace
safely and the `@typescript-eslint/no-explicit-any` lint error is removed.

apps/console/src/lib/use-crd-schema.ts-1-1 (1)

1-1: ⚠️ Potential issue | 🟡 Minor

Remove unused useQuery import.

ESLint flags this as unused. Since useK8sGet already encapsulates the query, the direct import is not needed.

-import { useQuery } from "@tanstack/react-query"
 import { useK8sGet } from "@cozystack/k8s-client"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/lib/use-crd-schema.ts` at line 1, Remove the unused import
of useQuery from the top of the file; the file currently imports useQuery but
relies on useK8sGet to encapsulate the query logic, so delete the import line
referencing useQuery to satisfy ESLint and avoid dead code.

apps/console/src/routes/BackupResourceListPage.tsx-117-124 (1)

117-124: ⚠️ Potential issue | 🟡 Minor

Status text falls back to raw "True"/"False" condition status.

When phase is absent, statusText becomes ready.status (literal "True"/"False"/"Unknown"), which is exposed to the user as the status label. That's confusing UX — users see "True" in a badge and have to infer it means "Ready".

♻️ Suggested mapping

-                  const phase = item.status?.phase
-                  const ready = item.status?.conditions?.find((c) => c.type === "Ready")
-                  const statusText = phase || ready?.status || "Unknown"
-                  const statusTone =
-                    statusText === "Completed" || statusText === "True" ? "ok" :
-                    statusText === "Failed" || statusText === "False" ? "error" :
-                    "warn"
+                  const phase = item.status?.phase
+                  const ready = item.status?.conditions?.find((c) => c.type === "Ready")
+                  const readyText =
+                    ready?.status === "True" ? "Ready"
+                    : ready?.status === "False" ? "Not Ready"
+                    : ready?.status === "Unknown" ? "Unknown"
+                    : undefined
+                  const statusText = phase || readyText || "Unknown"
+                  const statusTone =
+                    statusText === "Completed" || statusText === "Ready" ? "ok" :
+                    statusText === "Failed" || statusText === "Not Ready" ? "error" :
+                    "warn"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/BackupResourceListPage.tsx` around lines 117 - 124,
The UI shows raw condition statuses ("True"/"False") because statusText falls
back to ready.status; change the fallback to a user-facing label by mapping
ready.status values to friendly strings (e.g., "True" -> "Ready", "False" ->
"Not Ready", undefined/other -> "Unknown") where statusText is computed in the
items.map block, and then compute statusTone based on these mapped labels (or
check ready.status booleans first) so badges display "Ready"/"Not
Ready"/"Unknown" instead of raw "True"/"False"; update the logic around phase,
ready, statusText, and statusTone accordingly.

apps/console/src/routes/BackupResourceListPage.tsx-1-2 (1)

1-2: ⚠️ Potential issue | 🟡 Minor

Remove unused useNavigate import and navigate variable.

ESLint flags line 32 as unused. Since no in-component navigation happens here (deletion just refetches), drop both.

-import { Link, useNavigate } from "react-router"
+import { Link } from "react-router"
...
-  const navigate = useNavigate()

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/BackupResourceListPage.tsx` around lines 1 - 2, The
component imports and declares navigation utilities that are unused: remove the
unused import useNavigate and delete the navigate variable/const (from the
BackupResourceListPage component) so ESLint no longer flags it; keep Archive,
Plus, Edit, Trash2 and ensure deletion logic continues to only refetch without
performing any navigation.

apps/console/src/lib/use-crd-schema.ts-41-42 (1)

41-42: ⚠️ Potential issue | 🟡 Minor

Picking versions[0] is not guaranteed to be the served/storage version.

A CRD may declare multiple versions, and the first entry in spec.versions isn’t necessarily the one currently served or marked as storage. Prefer the version where storage === true (or served === true), falling back to versions[0] only if none is explicitly marked.

♻️ Suggested refactor

-  // Extract the schema from the first version's spec field
-  const schema = crd?.spec?.versions?.[0]?.schema?.openAPIV3Schema?.properties?.spec
+  // Prefer the storage version, then any served version, else fall back to the first.
+  const versions = crd?.spec?.versions ?? []
+  const chosen =
+    versions.find((v) => (v as CRDVersion & { storage?: boolean }).storage) ??
+    versions.find((v) => (v as CRDVersion & { served?: boolean }).served) ??
+    versions[0]
+  const schema = chosen?.schema?.openAPIV3Schema?.properties?.spec

You may also want to extend the CRDVersion interface with served?: boolean and storage?: boolean.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/lib/use-crd-schema.ts` around lines 41 - 42, The current
extraction uses versions[0] which may not be the served/storage version; update
the logic that computes schema to first find the CRD version where storage ===
true (or served === true if storage not present), falling back to versions[0]
only if no matching version is found, then read
thatVersion.schema.openAPIV3Schema.properties.spec; also extend the CRDVersion
type/interface to include optional served?: boolean and storage?: boolean to
accurately type-check the lookup.

apps/console/src/components/AdditionalPropertiesWidget.tsx-15-26 (1)

15-26: ⚠️ Potential issue | 🟡 Minor

Prefer inline validation over alert() for the duplicate-key case.

alert("Key "{newKey}" already exists") is blocking and inconsistent with the rest of the form’s styling. Consider surfacing the duplicate-key state inline (e.g., red border on the input + helper text) and/or disabling the Add button when newKey in (value ?? {}). This also lets keyboard users handle the error without dismissing a modal dialog.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/components/AdditionalPropertiesWidget.tsx` around lines 15 -
26, Replace the blocking alert in handleAddKey with inline validation: add a
local state (e.g., duplicateKeyError or isDuplicate) that checks newKey against
(value ?? {}) and set that state instead of calling alert; update the input to
show a validation state (red border/helper text) when duplicateKeyError is true
and disable the Add button when newKey is empty or duplicate; keep the rest of
the logic (using itemSchema to compute defaultValue, calling onChange and
setNewKey("")) unchanged so successful adds still work.

apps/console/src/routes/BackupCreatePage.tsx-106-145 (1)

106-145: ⚠️ Potential issue | 🟡 Minor

Replace alert() with inline/toast errors.

alert() is used for all four validation paths and the create-failure branch. This blocks the UI thread, can't be styled or localized, and diverges from the rest of this console app's UX (the same file uses <Section>, <Spinner>, etc. from @cozystack/ui). Prefer setting an error state rendered inline near the relevant field, or use a toast/notification primitive if one exists in @cozystack/ui.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/BackupCreatePage.tsx` around lines 106 - 145, Replace
all blocking alert() calls in handleSubmit with UI-friendly error reporting: use
local state (e.g., validationError / fieldErrors) to store per-field validation
messages and render them inline next to the corresponding inputs
(applicationRef, strategyRef, takenAt, name) instead of calling alert; for the
create-failure branch use the app’s notification/toast primitive (from
`@cozystack/ui`) or a global error state to show a non-blocking error containing
(err as Error).message; update handleSubmit to set these states where validation
fails and to show a toast on catch instead of alert, and ensure
createMutation.mutateAsync and navigate usage remain unchanged.

apps/console/src/components/KeyValueEditor.tsx-15-20 (1)

15-20: ⚠️ Potential issue | 🟡 Minor

Internal state doesn’t sync when the value prop changes.

The initial pairs list is built only once via the lazy useState initializer. If the parent updates value asynchronously — e.g., the wrapping CustomObjectFieldTemplate re-renders with data fetched from the server on an edit page, or another field’s change causes a schema reset — the editor will keep showing the initial (often empty) pairs. For the new backup edit flows this will look like the overrides silently disappeared.

Either derive pairs directly from value on each render, or add an effect that re-syncs when value changes from outside (e.g., using a shallow equality check to avoid clobbering in-progress edits).

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/components/KeyValueEditor.tsx` around lines 15 - 20, The
component initializes pairs via the lazy useState initializer and never updates
them when the incoming value prop changes; add sync logic so external changes to
value update pairs: either derive pairs from value on each render or add a
useEffect watching value that computes newPairs (map Object.entries(value || {})
to {key, value: typeof val === "string" ? val : JSON.stringify(val)}) and calls
setPairs only when the newPairs differ from the current pairs (use a shallow
equality check on keys/values to avoid clobbering in-progress edits). Refer to
the pairs state and setPairs and the initial useState initializer in
KeyValueEditor to locate where to apply the effect or derivation.

apps/console/src/routes/BackupCreatePage.tsx-129-145 (1)

129-145: ⚠️ Potential issue | 🟡 Minor

Guard submit when tenantNamespace is missing.

On line 134 the resource is built with namespace: tenantNamespace without a null check. If useTenantContext() hasn’t resolved a namespace, this sends namespace: undefined to createMutation.mutateAsync, which will either be rejected by the server or — worse — routed to the default namespace depending on the client. Add an early validation similar to the other alert checks, or disable the submit button while tenantNamespace is falsy.

🛡️ Proposed early check

     if (!formData.takenAt) {
       alert("Taken at timestamp is required")
       return
     }
+
+    if (!tenantNamespace) {
+      alert("No tenant namespace selected")
+      return
+    }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/BackupCreatePage.tsx` around lines 129 - 145, The
submit builds a resource using namespace: tenantNamespace without checking it;
add an early guard before constructing or calling createMutation.mutateAsync to
prevent sending namespace: undefined—e.g., if tenantNamespace is falsy alert the
user and return (similar to other alert checks) or ensure the submit button is
disabled while tenantNamespace is not set; reference the tenantNamespace
variable and the createMutation.mutateAsync call so you place the guard
immediately before resource construction/await createMutation.mutateAsync.

apps/console/src/components/SchemaForm.tsx-13-73 (1)

13-73: ⚠️ Potential issue | 🟡 Minor

Recursion misses array items and composite schemas.

Both addStorageClassWidgets and addAdditionalPropertiesWidgets only descend into schema.properties. A storageClass field inside an array item (e.g., volumes: { type: "array", items: { properties: { storageClass: {...} } } }) — which is common in CRD-driven schemas — will not pick up the widget, and likewise for schemas composed via allOf/oneOf/anyOf. Given the PR’s goal of applying StorageClassWidget to “all forms with a storageClass field”, this could silently miss real fields.

♻️ Suggested handling for array items (apply similarly to additionalProperties recursion)

   for (const [key, value] of Object.entries(properties)) {
     if (key === "storageClass" && typeof value === "object" && (value as any).type === "string") {
       // Found a storageClass field - add widget
       result[key] = {
         ...result[key],
         "ui:widget": "StorageClassWidget",
       }
     } else if (typeof value === "object" && (value as any).properties) {
       // Recursively process nested objects
       result[key] = addStorageClassWidgets(value as RJSFSchema, result[key] as UiSchema)
+    } else if (
+      typeof value === "object" &&
+      (value as any).type === "array" &&
+      (value as any).items &&
+      typeof (value as any).items === "object"
+    ) {
+      // Recurse into array item schemas
+      const items = (value as any).items
+      result[key] = {
+        ...result[key],
+        items: addStorageClassWidgets(items, (result[key] as UiSchema)?.items as UiSchema),
+      }
     }
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/components/SchemaForm.tsx` around lines 13 - 73, The current
recursion in addStorageClassWidgets and addAdditionalPropertiesWidgets only
traverses schema.properties and thus misses storageClass inside arrays and
composite schemas; update both functions to also descend into schema.items (for
arrays), schema.additionalProperties (when it is a schema), and each subschema
in schema.allOf/oneOf/anyOf by recursively calling the same function on those
schemas, and merge/attach uiSchema entries appropriately (e.g., propagate
result[key] to its .items or composite index entries) so StorageClassWidget and
AdditionalPropertiesField get applied for nested array items and composed
schemas; modify references inside addStorageClassWidgets and
addAdditionalPropertiesWidgets to detect and recurse into items,
additionalProperties, and allOf/oneOf/anyOf.

apps/console/src/components/StorageClassWidget.tsx-30-34 (1)

30-34: ⚠️ Potential issue | 🟡 Minor

Auto-default useEffect prevents users from clearing the field.

When the field is not required (line 44 renders -- None --), selecting it calls onChange(undefined) (line 39). On the very next render !value is true again, so this effect immediately re-fires and writes the default back — users can never intentionally leave the field empty on clusters that have a default StorageClass.

Use an init ref so the default is applied only once:

🐛 Proposed fix

-import { useEffect } from "react"
+import { useEffect, useRef } from "react"
 ...
 export function StorageClassWidget(props: WidgetProps) {
   const { value, onChange, required, disabled, readonly, placeholder } = props
+  const didInitRef = useRef(false)
   ...
-  // Set default storage class if value is empty and default exists
-  useEffect(() => {
-    if (!value && defaultSC && !isLoading) {
-      onChange(defaultSC.metadata.name)
-    }
-  }, [value, defaultSC, isLoading, onChange])
+  // Set default storage class once on first load if value is empty
+  useEffect(() => {
+    if (didInitRef.current || isLoading) return
+    if (!value && defaultSC) {
+      onChange(defaultSC.metadata.name)
+    }
+    didInitRef.current = true
+  }, [value, defaultSC, isLoading, onChange])

Also, placeholder is destructured on line 16 but never used (matches the ESLint hint) — drop it from the destructure.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/components/StorageClassWidget.tsx` around lines 30 - 34, The
current useEffect that auto-applies the default StorageClass repeatedly
re-triggers when value is falsy, preventing users from clearing the field;
change the logic in the useEffect in StorageClassWidget to only apply defaultSC
once by introducing an init ref (e.g., let appliedDefaultRef = useRef(false))
and only call onChange(defaultSC.metadata.name) when !appliedDefaultRef.current,
then set appliedDefaultRef.current = true after applying; also remove the unused
placeholder from the props destructure to satisfy ESLint.

apps/console/src/components/MutuallyExclusiveField.tsx-110-117 (1)

110-117: ⚠️ Potential issue | 🟡 Minor

Radio group name collides when title is undefined.

name={${title}-source} becomes "undefined-source" for any instance without a title; two such components on the same page will share a radio group and selecting one clears the other. Fall back to a unique identifier (e.g., a useId() value) instead of interpolating an optional string.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/components/MutuallyExclusiveField.tsx` around lines 110 -
117, The radio input name currently interpolates title
(name={`${title}-source`}) which yields "undefined-source" when title is missing
and causes distinct MutuallyExclusiveField instances to share a radio group;
update the component (MutuallyExclusiveField) to derive a stable fallback id
using React's useId() and use that id when title is falsy (e.g., const id =
useId(); const groupName = title ? `${title}-source` : `${id}-source`) and
assign groupName to the input name prop so each instance gets a unique radio
group when title is undefined.

apps/console/src/routes/BackupResourceCreatePageWithData.tsx-16-42 (1)

16-42: ⚠️ Potential issue | 🟡 Minor

Enum injection only descends into properties; misses items, oneOf, anyOf, schema-valued additionalProperties.

If a CRD schema wraps the target field in an array, a union, or a $ref-resolved allOf/oneOf branch, the dot-path walk will silently not hit it and the dropdown will render as a plain text input. Worth handling at least items and oneOf/anyOf, or logging a warning when an enumMap key does not resolve so misconfigurations don’t fail silently in the UI.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/BackupResourceCreatePageWithData.tsx` around lines 16
- 42, The enrichSchemaWithEnums function only traverses .properties so enums
nested under arrays, unions or schema-valued additionalProperties never get
injected; update enrichSchemaWithEnums to also descend into schema slots: check
and recurse into result.items, each branch of
result.oneOf/result.anyOf/result.allOf, and result.additionalProperties when
it's an object, and resolve $ref/allOf branches if your resolver is available;
after traversal, if enumMap contains keys that were not matched, emit a
warning/log with the unresolved path so misconfigurations don’t fail silently.
Ensure you reference enrichSchemaWithEnums and enumMap when adding these extra
recursion cases and the warning.

apps/console/src/routes/BackupPlanCreatePage.tsx-82-112 (1)

82-112: ⚠️ Potential issue | 🟡 Minor

Guard JSON.parse(baseSchema) and validate the enum map paths resolve.

Same pattern as BackupResourceCreatePageWithData.tsx — a malformed baseSchema will throw during render. Additionally, enrichSchemaWithEnums only walks properties, so any mismatch between the dot-paths here (applicationRef.kind, applicationRef.name, backupClassName) and the actual CRD schema shape fails silently. Consider logging when a path in enumMap did not match any node during enrichment to catch schema drift early.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/BackupPlanCreatePage.tsx` around lines 82 - 112, The
JSON.parse(baseSchema) call inside the useMemo may throw on malformed input and
the enumMap keys may not resolve to nodes that enrichSchemaWithEnums actually
walks, so wrap JSON.parse(baseSchema) in a safe parse (try/catch) and return
null on parse failure; before calling enrichSchemaWithEnums validate that the
dot-paths you set on enumMap (e.g. "applicationRef.kind", "applicationRef.name",
"backupClassName") actually resolve into the parsed base schema (check nested
properties via the same property traversal logic used by enrichSchemaWithEnums
or reuse a helper to resolve paths) and only add entries that resolve; also
modify or augment enrichSchemaWithEnums to emit a log/warning when a requested
enum path cannot be found so schema drift is visible (or capture missing-paths
here and log them via your logger) and finally keep the existing default
assignment on enriched.properties.applicationRef.properties.apiGroup only after
confirming those nested objects exist.

apps/console/src/components/rjsf-templates.tsx-1-14 (1)

1-14: ⚠️ Potential issue | 🟡 Minor

Remove unused imports.

ESLint flags FieldTemplateProps (line 5) and AdditionalPropertiesField (line 14) as unused. AdditionalPropertiesField in particular isn’t registered anywhere in this registry — dead import.

Suggested diff

 import type {
   IconButtonProps,
   TemplatesType,
   WidgetsType,
-  FieldTemplateProps,
   FormContextType,
   RJSFSchema,
   StrictRJSFSchema,
 } from "@rjsf/utils"
 import { CustomObjectFieldTemplate } from "./CustomObjectFieldTemplate.tsx"
 import { SourceWidget } from "./SourceWidget.tsx"
 import { StorageClassWidget } from "./StorageClassWidget.tsx"
 import { AdditionalPropertiesWidget } from "./AdditionalPropertiesWidget.tsx"
-import { AdditionalPropertiesField } from "./AdditionalPropertiesField.tsx"

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/components/rjsf-templates.tsx` around lines 1 - 14, Remove
the dead imports flagged by ESLint: delete the unused FieldTemplateProps import
and the never-registered AdditionalPropertiesField import from the top of the
rjsf templates module; ensure only used symbols (e.g., IconButtonProps,
TemplatesType, WidgetsType, FormContextType, RJSFSchema, StrictRJSFSchema)
remain so imports match actual usage in this file (references:
FieldTemplateProps, AdditionalPropertiesField).

apps/console/src/components/AdditionalPropertiesField.tsx-26-37 (1)

26-37: ⚠️ Potential issue | 🟡 Minor

Trim inconsistency lets users create whitespace-padded duplicate keys.

newKey.trim() gates acceptance on line 27, but the duplicate check on line 28 and the key write on line 35 use the raw newKey. A user entering "foo" followed by " foo " creates two distinct entries. Normalize once and reuse.

🐛 Suggested fix

   const handleAddKey = () => {
-    if (!newKey.trim()) return
-    if (formData && newKey in formData) {
-      alert(`Key "${newKey}" already exists`)
+    const trimmed = newKey.trim()
+    if (!trimmed) return
+    if (formData && trimmed in formData) {
+      alert(`Key "${trimmed}" already exists`)
       return
     }

     // Initialize with default value from schema
     const defaultValue = itemSchema.type === "object" ? {} : itemSchema.default ?? ""
-    onChange({ ...formData, [newKey]: defaultValue })
+    onChange({ ...formData, [trimmed]: defaultValue })
     setNewKey("")
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/components/AdditionalPropertiesField.tsx` around lines 26 -
37, In handleAddKey normalize newKey once (e.g., const trimmedKey =
newKey.trim()) and use trimmedKey for the empty check, duplicate check (against
formData), the key inserted into onChange, and the alert text; keep
setNewKey("") (or setNewKey(trimmedKey) then clear) to avoid creating
whitespace-padded duplicate keys and ensure consistency when using itemSchema,
formData, onChange and setNewKey.

apps/console/src/routes/BackupResourceCreatePage.tsx-76-127 (1)

76-127: ⚠️ Potential issue | 🟡 Minor

Missing “schema failed to load” fallback — sibling pages render an error, this one renders a blank form.

When schemaLoading is false and schema is still falsy (either crdSchema missing and no overrideSchema), the header + empty Name input render with no indication that the form is broken. BackupPlanCreatePage and BackupRestoreJobCreatePage both handle this with an explicit !schema branch — worth aligning for UX consistency.

   if (schemaLoading) {
     return (
       <div className="flex items-center gap-2 p-8 text-slate-500">
         <Spinner /> Loading schema...
       </div>
     )
   }
+
+  if (!schema) {
+    return (
+      <div className="p-8 text-red-600">
+        Failed to load {title} schema. Please refresh the page.
+      </div>
+    )
+  }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/BackupResourceCreatePage.tsx` around lines 76 - 127,
The page currently shows the header and Name input when schemaLoading is false
but schema is falsy, leaving the form broken; add the same explicit !schema
fallback used in BackupPlanCreatePage and BackupRestoreJobCreatePage so users
see an error state instead of an empty form. After the schemaLoading check in
BackupResourceCreatePage, add a branch that checks if (!schema) and returns the
same error UI (message + possible retry/navigation control) used by the sibling
pages, ensuring SchemaForm (openAPISchema prop) and the rest of the form are not
rendered when schema is missing; reference the schemaLoading and schema
variables and the SchemaForm/handleSubmit components to locate where to insert
this fallback.

apps/console/src/routes/BackupResourceCreatePageWithData.tsx-86-139 (1)

86-139: ⚠️ Potential issue | 🟡 Minor

JSON.parse(baseSchema) can throw inside useMemo.

If useCRDSchema ever returns a non-JSON string (e.g., an error payload, partial response), the throw propagates out of render and there is no user-visible fallback. Wrap in try/catch and render the same error state as !schema.

🛡️ Suggested guard

   const enrichedSchema = useMemo(() => {
     if (!baseSchema) return null

-    const base = JSON.parse(baseSchema)
+    let base: any
+    try {
+      base = JSON.parse(baseSchema)
+    } catch (err) {
+      console.error("Failed to parse CRD schema", err)
+      return null
+    }
     const enumMap: Record<string, string[]> = {}

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/BackupResourceCreatePageWithData.tsx` around lines 86
- 139, The JSON.parse(baseSchema) call inside the useMemo that computes
enrichedSchema can throw and crash rendering; wrap the parse/enrichment logic in
a try/catch within the useMemo (the function where enrichedSchema is computed)
and on error return null (same as the !schema case) so the component renders the
existing error/fallback UI; ensure you still compute enumMap and call
enrichSchemaWithEnums only when parsing succeeds, and keep the same dependency
list ([baseSchema, resourceType, appDefs, plansData, backupsData,
backupClassesData]).

apps/console/src/components/AdditionalPropertiesEditor.tsx-33-33 (1)

33-33: ⚠️ Potential issue | 🟡 Minor

Avoid alert() for duplicate-key feedback.

Blocking alert() is inconsistent with the rest of the console UI. Prefer inline validation text next to the input (e.g., a red helper label) or a toast. This also improves a11y.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/components/AdditionalPropertiesEditor.tsx` at line 33,
Replace the blocking alert call used for duplicate keys in
AdditionalPropertiesEditor (the code path using newKey) with non-blocking UI
feedback: update the component's state (e.g., set a validation error like
setKeyError or inlineValidation) so an inline red helper label appears beside
the input, or trigger the app's toast mechanism (e.g., call showToast or
setToast) instead of alert; adjust the add-property handler (handleAddProperty /
onAddProperty) to check the existing properties list and set the validation
state or toast when a duplicate is detected, and ensure the input field uses
that validation state to render the helper text and aria-describedby for
accessibility.

apps/console/src/routes/BackupResourceEditPage.tsx-79-79 (1)

79-79: ⚠️ Potential issue | 🟡 Minor

Replace alert() with the app's toast/notification primitive.

Native alert() is blocking, not styled, and inconsistent with the rest of the console UI. Use the shared toast component for error feedback, and ideally surface the error inline near the Save button as well.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/BackupResourceEditPage.tsx` at line 79, Replace the
blocking native alert in BackupResourceEditPage (the alert(`Failed to update
${title.slice(0, -1)}: ${(err as Error).message}`) call) with the app's shared
toast/notification primitive: import and call the toast API used across the
console (e.g., toast.error(...) or showToast({type: 'error', title: 'Update
failed', message: ...})) and pass the same formatted message; additionally set a
local component state like saveError and update it with the error message so the
UI can render an inline error message near the Save button (clear saveError when
retrying or on success). Ensure you remove the alert() call and use the toast
API plus the saveError state in the Save handler in BackupResourceEditPage.

apps/console/src/components/AdditionalPropertiesEditor.tsx-30-41 (1)

30-41: ⚠️ Potential issue | 🟡 Minor

Trimmed for validation, stored raw — keys with whitespace slip through.

handleAddKey validates !newKey.trim() and checks duplicates against the raw newKey, but stores newKey verbatim on line 39. A user entering " foo " creates a key " foo " that won't collide with an existing "foo" and displays with stray whitespace. Normalize once and reuse.

🔧 Suggested fix

   const handleAddKey = () => {
-    if (!newKey.trim()) return
-    if (value && newKey in value) {
-      alert(`Key "${newKey}" already exists`)
+    const key = newKey.trim()
+    if (!key) return
+    if (value && key in value) {
+      alert(`Key "${key}" already exists`)
       return
     }
 
     // Initialize with default value from schema
     const defaultValue = itemSchema.type === "object" ? {} : itemSchema.default ?? ""
-    onChange({ ...value, [newKey]: defaultValue })
+    onChange({ ...value, [key]: defaultValue })
     setNewKey("")
   }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/components/AdditionalPropertiesEditor.tsx` around lines 30 -
41, handleAddKey uses newKey.trim() for validation but then stores the raw
newKey, allowing keys with surrounding whitespace; fix by normalizing newKey
once at start (e.g., const normalizedKey = newKey.trim()), use normalizedKey for
the duplicate check (against value), use normalizedKey when adding the property
in onChange (with defaultValue computed from itemSchema), and then clear the
input with setNewKey(""); update all references in handleAddKey to the
normalizedKey so whitespace can't create distinct keys.

apps/console/src/routes/BackupResourceEditPage.tsx-65-65 (1)

65-65: ⚠️ Potential issue | 🟡 Minor

Import FormEvent as a named import instead of using React.FormEvent.

The file uses React.FormEvent without importing the React namespace. With the modern JSX transform ("jsx": "react-jsx"), the React namespace is not automatically in scope. Only useEffect and useState are imported from react. Update to use the named import:

🔧 Proposed fix

-import { useEffect, useState } from "react"
+import { useEffect, useState, type FormEvent } from "react"
@@
-  const handleSubmit = async (e: React.FormEvent) => {
+  const handleSubmit = async (e: FormEvent) => {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/routes/BackupResourceEditPage.tsx` at line 65, The handler
signature uses React.FormEvent but the React namespace isn't imported under the
modern JSX transform; update the import from 'react' to include the named type
FormEvent (alongside existing useEffect/useState), and change the function
signature to use FormEvent (e.g., handleSubmit = async (e: FormEvent) => { ...
}) so the type resolves correctly; locate the handleSubmit function and the
top-level import that currently imports useEffect/useState and add FormEvent
there.

apps/console/src/components/AdditionalPropertiesEditor.tsx-38-38 (1)

38-38: ⚠️ Potential issue | 🟡 Minor

Handle type arrays in default value initialization.

RJSFSchema.type supports string | string[] per JSON Schema Draft 7 spec (e.g., ["object", "null"]). The current check itemSchema.type === "object" only works for string types and fails for arrays, defaulting to "" which may be invalid for object types.

Normalize the type check:

Suggested fix

-    const defaultValue = itemSchema.type === "object" ? {} : itemSchema.default ?? ""
+    const types = Array.isArray(itemSchema.type) ? itemSchema.type : [itemSchema.type]
+    const defaultValue =
+      itemSchema.default ??
+      (types.includes("object") ? {} : types.includes("array") ? [] : "")

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/console/src/components/AdditionalPropertiesEditor.tsx` at line 38, The
defaultValue initialization incorrectly treats itemSchema.type as a string only;
update the check so it handles string or string[] (per RJSFSchema.type) by
detecting arrays and testing includes('object') — e.g., replace the single
equality check with a boolean like (Array.isArray(itemSchema.type) ?
itemSchema.type.includes("object") : itemSchema.type === "object") when deciding
to use {} versus itemSchema.default ?? "". Ensure you keep the existing fallback
to itemSchema.default and then "" as before; reference variable defaultValue and
the itemSchema.type property.